In a 3D graphics system, the pixels on which a 3D image is to be rendered are typically subdivided into a plurality of rectangular areas or tiles. For example, in the applicant's UK Patent No. 2298111, the image is divided into tiles and the tiles are processed in turn. For convenience, these tiles are often grouped into what is known as macro tiles. Typically, a geometry processing unit receives image data from an application and transforms it into screen space using a well known method. The data is then supplied to a tiling unit which inserts the screen space geometry into object lists for each set of defined rectangular regions or tiles. Each of these lists will contain primitives (surfaces typically defined as triangles) that exist wholly or partially in a sub region of a screen, i.e. a tile. Therefore, there will be an object list for every tile on the screen. The tiles can then be rendered in turn using any known method until all the objects within each tile are processed.
Various methods are known for determining the depth of primitives for a particular pixel in a tile. These enable hidden surfaces to be removed and subsequently not processed for a pixel unless the closest surface to a view point is translucent. Typically, primitives will have tags associated with them indicating whether they are translucent or opaque.
An example of such a known rendering system is shown in FIG. 1, which is a schematic block diagram of a known rendering system. The rendering system comprises a Geometry Processing unit 2 which receives primitive data defining objects. This processes the objects to derive primitives such as triangles which are passed to a Tiling unit 4 which subdivides the image to be textured and shaded into a plurality of rectangular areas. Tile geometry lists are then produced in Tiled Screen Space Geometry Lists unit 6. These comprise lists of primitives which are potentially visible in each tile. A Hidden Surface Removal unit 8 then determines which surface or surfaces defined by the primitives are visible at each pixel in a tile before passing the data to a Texturing and Shading unit 10 which can apply texture and shading to the pixels, depending upon image attributes associated with the objects determined to be visible at each pixel.
Various methods are known for determining relative depths and also for determining whether it is appropriate to render data for a particular pixel or tile. One such system is shown in the applicant's International patent application number PCT/GB2004/002717 (publication number WO2005/015503). In this, for each pixel in a tile, objects are considered in turn in a depth sorting unit, with data relating to translucency. When a translucent object covers an opaque object at a pixel, data for the whole tile is flushed to a shading and texturing unit.
In previous embodiments, each triangle was assigned a unique entry in a lookup table (LUT), rather than sharing LUT entries for triangles with similar states. The processing order of spans was also line based, rather than micro tile oriented. This meant that it was impossible to associate triangles with left and right regions, because the whole width of a tile was considered in a single cycle. Because each triangle took a single LUT entry, this meant the LUT had to be large and expensive. The cost becomes more prohibitive as the tile becomes larger, as more triangles need to be stored in the LUT. However, this does enable a bounding box for each triangle (in this case a Y minimum and maximum since the whole width of the tile is considered at once) to be stored in the LUT. This meant that the outputting process becomes very simple. Initially the TAG ID Buffer is scanned to determine which LUT IDs are still visible after the processing of the pass (objects may be obscured by other objects appearing in front). Then the visible spans for the visible triangles (1 Triangle=1 LUT ID) are outputted, starting with the lowest LUT ID. Each LUT entry contains the original extent (Y Minimum to Y maximum) for the triangle, and the TAG ID Buffer is scanned for this extent to output the triangle.
In a deferred Z buffer system, a rasterisation pipeline receives a stream of primitives which intersect with a tile currently being processed. The information is received by a depth sorter which calculates the depth and rasterises the received triangle to determine whether or not the sample is visible. That is to say, it determines whether the primitive is in front of the previous objects for that pixel position in the Z buffer, and whether or not it is translucent.
If appropriate, the depth stored for a particular pixel may be updated and a mask indicating which samples should be textured and shaded for each pixel is passed to a tag sorter, which uses object data and associated tags for each pixel in texturing and shading.